Background and Relevant Art
Increasing advances in computer technology (e.g., microprocessor speed, memory capacity, data transfer bandwidth, software functionality, and the like) have generally contributed to increased computer application in various industries. Ever more powerful server systems, which are often configured as an array of servers, are often provided to service requests originating from external sources such as the World Wide Web, for example. As local Intranet systems have become more sophisticated thereby requiring servicing of larger network loads and related applications, internal system demands have grown accordingly as well. As such, much business data is stored in databases, under the management of a database management system (DBMS).
For such DBMS systems, a demand for database transaction processing capacity in large installations has been growing significantly. At the same time, a large percentage of overall new database applications have been in a relational database environment. Such relational database can further provide an ideal environment for supporting various forms of queries on the database. For example, a growth in the use of ad hoc unstructured concomitant queries—is a trend that is expected to accelerate in such database environments. This can result in a growing requirement for simultaneously supporting both high volume transaction processing and unstructured queries against the same database. Thus, systems and methodologies that can effectively support both high volume transactions and complex queries, with minimal interference between the two, while sharing copies of data are in demand.
Typically, business entities create and maintain their databases through a high volume of relatively simple transactions, with an essential function of a database engine being able to execute a plurality of such transactions concurrently. Each of such plurality of transactions can be considered a piece of work, which can further consist of a sequence of operations such as, read, write, update, and/or delete, against a database. Such transaction can represent well-understood business operations (e.g., creating a new customer record, noting an account payment or transfer, and the like). Increasingly enterprises are becoming interested in running more ad hoc unstructured queries against their online data. As such, a measure of the correctness of the state of the database or a database integrity becomes increasingly vital.
In general database integrity can refer to the problem of ensuring that two or more concurrently executing transactions do not interfere with each other in such a manner as to produce an incorrect state in the database. An application programmer typically should ensure that each transaction produces a correct state, and that each transaction begins when the database is in a correct state. Such transaction management should generally adhere to the ACID (Atomicity, Consistency, Isolation and Durability) standards. When multiple copies of data pages are created, such standards can be difficult to adhere to.
To facilitate adherence to such standards, conventional procedures employ a number of techniques to assist in maintaining ACID properties—including logging and shadow paging. In general, an approach that maintains multiple copies of database pages offers some advantages in the simplicity of implementation, but also introduces some complexities of its own. For example, during a commit stage of data modifications upon shared resources via shadow paging techniques, additional over head for merging purposes can be required, which can typically impede efficient commit operations for concurrent transactions. Similarly, employing log records can in general add to the complexity of the database management and recovery. At the same time, the more efficiently a database engine supports concurrent transactions, the better an end-user experience can be in terms of speed of operation and reduced database growth.
While applications are interacting with a database system, the database system will typically employ a function referred to a locking to ensure that data the applications are modifying is not modified by another application or process. In general, such locking of the data can prevent users from changing the same data at the same time. If such locking mechanisms do not operate properly, data can become logically incorrect, and future use of the data can produce unexpected results. In addition, multiple transactions trying to use the same data concurrently can give rise to several different types of problems referred to as concurrency problems.
Such problems can cause updates of data by one application to be lost or overwritten by another application. Sometimes data is modified, but not immediately written out in a manner that it can be read by other applications. This can also result in reads of data which should be the same, not being the same.
Therefore, there is a need to overcome the aforementioned deficiencies associated with conventional systems and methodologies related to database operations.